There's no data to suggest this is accurate. The issue this fixes, for example, demonstrates no_std doesn't work.

This PR just clarifies that the windows-sys crate explicitly supports no_std compilation. This is compiler-enforced but if that's not helpful to include in the FAQ then I'm happy to ditch it.

https://doc.rust-lang.org/reference/names/preludes.html#the-no_std-attribute

Again, this has nothing to do with whether or not the CRT is linked into a given downstream binary. The windows-sys crate has no control over that. Anyway, I'll close this for now.

IMHO, the no_std support for windows-sys is one of the biggest motivating factors for using it instead of windows (the others being compile times and stability).

As Kenny says, this has nothing to do with no-CRT support (which is a very very niche requirement) and in either case that has nothing to do with the windows-sys crate itself. It will support whatever the toolchain supports and has no requirements beyond core.